sunxin's Studio.

Activity 的启动流程源码分析（Android 9.0）

源码分析
字数统计: 2.3k阅读时长: 11 min
2019/11/26 Share

Activity 的启动流程源码分析（Android 9.0）

本篇的源码分析基于Android 9 ，targetSdkVersion 为28

首先，分析启动流程就要先找到源头，也就是程序的入口，Android启动流程的入口就在 ActivityThread的 main方法中，简短的贴下，省略的一些代码

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
public static void main(String[] args) {
 
		// 开启一个主线程的Looper
    Looper.prepareMainLooper();

 		// 直接new了一个ActivityThread
    ActivityThread thread = new ActivityThread();
    // 进行关联操作
    thread.attach(false, startSeq);

    if (sMainThreadHandler == null) {
        sMainThreadHandler = thread.getHandler();
    }

    if (false) {
        Looper.myLooper().setMessageLogging(new
                LogPrinter(Log.DEBUG, "ActivityThread"));
    }

    // End of event ActivityThreadMain.
    Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER);
    Looper.loop();

    throw new RuntimeException("Main thread loop unexpectedly exited");
}

在main方法中使用了 Handler消息机制，开启了一个主线程的消息循环，然后在这里面直接创建了 ActivityThread 对象，并进行了 attach操作。看一下 attach方法到底关联了什么。

1
2
3
4
5
6
7
8
9
10
private void attach(boolean system, long startSeq) {
    // 这里实际上是通过Binder机制获取到了ActivityManagerService 对象
    final IActivityManager mgr = ActivityManager.getService();
            try {
                // 然后在AMS中进行关联Application
                mgr.attachApplication(mAppThread, startSeq);
            } catch (RemoteException ex) {
                throw ex.rethrowFromSystemServer();
            }
}

来到 ActivityManager 中看下 getService()方法

1
2
3
4
5
6
7
8
9
10
11
12
13
14
public static IActivityManager getService() {
    return IActivityManagerSingleton.get();
}

private static final Singleton<IActivityManager> IActivityManagerSingleton =
        new Singleton<IActivityManager>() {
            @Override
            protected IActivityManager create() {
                // Binder 跨进程调用获取到am
                final IBinder b = ServiceManager.getService(Context.ACTIVITY_SERVICE);
                final IActivityManager am = IActivityManager.Stub.asInterface(b);
                return am;
            }
        };

继续回到 attach 方法中，我们知道了是在 ActivityManagerService中进行了 attachApplication ，先来到AMS中

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
// 继承了 IActivityManager
public class ActivityManagerService extends IActivityManager.Stub{
  
   
    @Override
    public final void attachApplication(IApplicationThread thread, long startSeq) {
        synchronized (this) {
           // 获取到一些id
            int callingPid = Binder.getCallingPid();
            final int callingUid = Binder.getCallingUid();
            final long origId = Binder.clearCallingIdentity();
            // 重点关注这个方法
            attachApplicationLocked(thread, callingPid, callingUid, startSeq);
            Binder.restoreCallingIdentity(origId);
        }
    }
}

attachApplicationLocked 方法的第一个参数是 IApplicationThread ，这个类是 ActivityThread 的内部类 ApplicationThread 的父类

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
@GuardedBy("this")
private final boolean attachApplicationLocked(IApplicationThread thread,
        int pid, int callingUid, long startSeq) {
  
   if (app.isolatedEntryPoint != null) {
      // This is an isolated process which should just call an entry point instead of
      // being bound to an application.
  thread.runIsolatedEntryPoint(app.isolatedEntryPoint,app.isolatedEntryPointArgs);
            // 如果进程记录的一些参数不为空
            } else if (app.instr != null) {
       					// 开始绑定Application,然后创建Application
                thread.bindApplication(processName, appInfo, providers,
                        app.instr.mClass,
                        profilerInfo, app.instr.mArguments,
                        app.instr.mWatcher,
                        app.instr.mUiAutomationConnection, testMode,
                        mBinderTransactionTrackingEnabled, enableTrackAllocation,
                        isRestrictedBackupMode || !normalMode, app.persistent,
                        new Configuration(getGlobalConfiguration()), app.compat,
                        getCommonServicesLocked(app.isolated),
                        mCoreSettingsObserver.getCoreSettingsLocked(),
                        buildSerial, isAutofillCompatEnabled);
            } else {
     						// 进程记录的一些参数为null
                thread.bindApplication(processName, appInfo, providers, null, profilerInfo,
                        null, null, null, testMode,
                        mBinderTransactionTrackingEnabled, enableTrackAllocation,
                        isRestrictedBackupMode || !normalMode, app.persistent,
                        new Configuration(getGlobalConfiguration()), app.compat,
                        getCommonServicesLocked(app.isolated),
                        mCoreSettingsObserver.getCoreSettingsLocked(),
                        buildSerial, isAutofillCompatEnabled);
            }
  
  
      // See if the top visible activity is waiting to run in this process...
        if (normalMode) {
            try {
                // Activity栈管理者，先占个坑，待会儿别忘了
                if (mStackSupervisor.attachApplicationLocked(app)) {
                    didSomething = true;
                }
            } catch (Exception e) {
                Slog.wtf(TAG, "Exception thrown launching activities in " + app, e);
                badApp = true;
            }
        }
  
}

接下来先看 bindApplication，之后记得回头研究一下 mStackSupervisor.attachApplicationLocked(app) 干了什么

我们知道了 thread 是 ActivityThread内部类 ApplicationThread的父类，要去子类中找父类的方法，来到 ApplicationThread 看下 bindApplication 方法

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
private class ApplicationThread extends IApplicationThread.Stub {
  
  public final void bindApplication(String processName, ApplicationInfo appInfo,
                List<ProviderInfo> providers, ComponentName instrumentationName,
                ProfilerInfo profilerInfo, Bundle instrumentationArgs,
                IInstrumentationWatcher instrumentationWatcher,
                IUiAutomationConnection instrumentationUiConnection, int debugMode,
                boolean enableBinderTracking, boolean trackAllocation,
                boolean isRestrictedBackupMode, boolean persistent, Configuration config,
                CompatibilityInfo compatInfo, Map services, Bundle coreSettings,
                String buildSerial, boolean autofillCompatibilityEnabled) {

   				 // 参数老长了       
    
            AppBindData data = new AppBindData();
            data.processName = processName;
            data.appInfo = appInfo;
            data.providers = providers;
    
            ...
             // 看到这里，发送了一个绑定Application的消息出去，携带了一些绑定数据
            sendMessage(H.BIND_APPLICATION, data);
        }
}

通过 Handler 发送消息，要去看一下这个消息是如何处理的，找到 handleMessage

1
2
3
4
5
6
7
8
9
10
11
public void handleMessage(Message msg) {
  
  switch (msg.what) {
    case BIND_APPLICATION:
      Trace.traceBegin(Trace.TRACE_TAG_ACTIVITY_MANAGER, "bindApplication");
      AppBindData data = (AppBindData)msg.obj;
      // 处理绑定
      handleBindApplication(data);
      Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER);
      break;
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
private void handleBindApplication(AppBindData data) {
  
  ...
    
  // Do this after providers, since instrumentation tests generally start their
  // test thread at this point, and we don't want that racing.
  try {
    // 这里先创建一个 Instrumentation，可以用来监控Application和系统的交互,和生命周期有关
    mInstrumentation.onCreate(data.instrumentationArgs);
  }
  catch (Exception e) {
    throw new RuntimeException(
      "Exception thrown in onCreate() of "
      + data.instrumentationName + ": " + e.toString(), e);
  }
  try {
    // 这里就调用创建 Application的方法
    mInstrumentation.callApplicationOnCreate(app);
  } catch (Exception e) {
    if (!mInstrumentation.onException(app, e)) {
      throw new RuntimeException(
        "Unable to create application " + app.getClass().getName()
        + ": " + e.toString(), e);
    }
  }
}

看一下 callApplicationOnCreate

1
2
3
4
5
6
public class Instrumentation {
  public void callApplicationOnCreate(Application app) {
       // 这里就调用 Application 的 onCreate()方法
        app.onCreate();
    }
}

至此，Application创建完毕。

好了，现在可以回过头来，补之前的一个坑，现在开始研究一下 mStackSupervisor.attachApplicationLocked(app) 这个方法将走向何方，看下 ActivityStackSupervisor，见名知意，Activity栈的管理者.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
public class ActivityStackSupervisor extends ConfigurationContainer implements DisplayListener,RecentTasks.Callbacks {
  
  // 关联
  boolean attachApplicationLocked(ProcessRecord app) throws RemoteException {
 
    // 从栈中获取所有运行并且可见的ActivityRecord（代表Activity）放入到List中
    stack.getAllRunningVisibleActivitiesLocked(mTmpActivityList);
    // 获取栈顶的ActivityRecord
    final ActivityRecord top = stack.topRunningActivityLocked();
    final int size = mTmpActivityList.size();
    // 遍历所有记录
    for (int i = 0; i < size; i++) {
      final ActivityRecord activity = mTmpActivityList.get(i);
      if (activity.app == null && app.uid == activity.info.applicationInfo.uid
          && processName.equals(activity.processName)) {
        try {
          // 如果上面的条件都符合，那就真的要开启Activity了啊！
          if (realStartActivityLocked(activity, app,
                                      top == activity /* andResume */, true /* checkConfig */)) {
            didSomething = true;
          }
        } catch (RemoteException e) {
          Slog.w(TAG, "Exception in new application when starting activity "
                 + top.intent.getComponent().flattenToShortString(), e);
          throw e;
        }
      }
    } 
  }
  
}

我们来看一看如何真的开启Activity

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
final boolean realStartActivityLocked(ActivityRecord r, ProcessRecord app,
        boolean andResume, boolean checkConfig) throws RemoteException {
  
     // Create activity launch transaction.
    // 创建 Activity 的启动事务
    final ClientTransaction clientTransaction = ClientTransaction.obtain(app.thread,
                        r.appToken);
    // 添加 LaunchActivityItem，记住这里，后面会从这里获取这个item
    clientTransaction.addCallback(LaunchActivityItem.obtain(new Intent(r.intent),
                        System.identityHashCode(r), r.info,
                        // TODO: Have this take the merged configuration instead of separate global
                        // and override configs.
                        mergedConfiguration.getGlobalConfiguration(),
                        mergedConfiguration.getOverrideConfiguration(), r.compat,
                        r.launchedFromPackage, task.voiceInteractor, app.repProcState, r.icicle,
                        r.persistentState, results, newIntents, mService.isNextTransitionForward(),
                        profilerInfo));

                // Set desired final state.
  
  final ActivityLifecycleItem lifecycleItem;
  if (andResume) {
    // 如果是resume，就获取一个ResumeActivityItem
    lifecycleItem = ResumeActivityItem.obtain(mService.isNextTransitionForward());
  } else {
    lifecycleItem = PauseActivityItem.obtain();
  }
  clientTransaction.setLifecycleStateRequest(lifecycleItem);

  // Schedule transaction.
  // 安排事务，继续这个方法往下走
  mService.getLifecycleManager().scheduleTransaction(clientTransaction);
  
}

进来 ClientLifecycleManager 

1
2
3
4
5
6
7
class ClientLifecycleManager {
  void scheduleTransaction(ClientTransaction transaction) throws RemoteException {
        final IApplicationThread client = transaction.getClient();
        transaction.schedule();
  			...
    }
}

go on,找到 ClientTransaction

1
2
3
4
5
/** Target client. */
private IApplicationThread mClient
public void schedule() throws RemoteException {
    mClient.scheduleTransaction(this);
}

继续继续继续，IApplicationThread 这里又回到了 ActivityThread

1
2
3
4
@Override
public void scheduleTransaction(ClientTransaction transaction) throws RemoteException {
    ActivityThread.this.scheduleTransaction(transaction);
}

ActivityThread 继承了 ClientTransactionHandler,所以上面的方法又进入了这里

1
2
3
4
5
6
7
8
9
10
public abstract class ClientTransactionHandler {
  
   /** Prepare and schedule transaction for execution. */
    void scheduleTransaction(ClientTransaction transaction) {
        transaction.preExecute(this);
        // 这里又发送一个消息到ActivityThread
        sendMessage(ActivityThread.H.EXECUTE_TRANSACTION, transaction);
    }
  
}

继续看 handleMessage方法怎么处理的

1
2
3
4
5
6
7
8
9
10
11
public void handleMessage(Message msg) {
    
    switch (msg.what) {
       case EXECUTE_TRANSACTION:
        final ClientTransaction transaction = (ClientTransaction) msg.obj;
        // TransactionExecutor 在这里去执行了 transaction
        mTransactionExecutor.execute(transaction);
     		...
         break;
    }
}

进来 TransactionExecutor 看一下如何执行的

1
2
3
4
5
6
7
8
9
10
11
public void execute(ClientTransaction transaction) {
  // 看到了Binder
    final IBinder token = transaction.getActivityToken();
    log("Start resolving transaction for client: " + mTransactionHandler + ", token: " + token);
		// 看这里
    executeCallbacks(transaction);
    // 稍后看这里，别忘了
    executeLifecycleState(transaction);
    mPendingActions.clear();
    log("End resolving transaction");
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
@VisibleForTesting
public void executeCallbacks(ClientTransaction transaction) {
   // 这里把之前 addCallback 存进去的 item 取出来
   final List<ClientTransactionItem> callbacks = transaction.getCallbacks();
  
  ...
    
   final int size = callbacks.size();
  // 遍历循环所有的item
  for (int i = 0; i < size; ++i) {
    final ClientTransactionItem item = callbacks.get(i);
    log("Resolving callback: " + item);
    final int postExecutionState = item.getPostExecutionState();
    final int closestPreExecutionState = mHelper.getClosestPreExecutionState(r,
                                                                          item.getPostExecutionState());
    
    // 在这里开始执行，这个Item就是 LaunchActivityItem
    item.execute(mTransactionHandler, token, mPendingActions);
    item.postExecute(mTransactionHandler, token, mPendingActions);
    if (r == null) {
      // Launch activity request will create an activity record.
      r = mTransactionHandler.getActivityClient(token);
    }

  }
}

进来 LaunchActivityItem 看一下 execute 

1
2
3
4
5
6
7
8
9
10
11
12
@Override
public void execute(ClientTransactionHandler client, IBinder token,
        PendingTransactionActions pendingActions) {
    
    ActivityClientRecord r = new ActivityClientRecord(token, mIntent, mIdent, mInfo,
            mOverrideConfig, mCompatInfo, mReferrer, mVoiceInteractor, mState, mPersistentState,
            mPendingResults, mPendingNewIntents, mIsForward,
            mProfilerInfo, client);
  	// 看到这里大概就有点眼熟了，client是 ActivityThread的父类
    client.handleLaunchActivity(r, pendingActions, null /* customIntent */);
   
}

再次回到 ActivityThread 

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
@Override
public Activity handleLaunchActivity(ActivityClientRecord r,
        PendingTransactionActions pendingActions, Intent customIntent) {
  
   ...
     
   final Activity a = performLaunchActivity(r, customIntent);
  
  ...
  
}

 /**  Core implementation of activity launch. */
private Activity performLaunchActivity(ActivityClientRecord r, Intent customIntent) {
  
  ...
      // 有没有需要恢复的数据
      if (r.isPersistable()) {
        // 再次去到 Instrumentation ，调用Activity的create方法
        mInstrumentation.callActivityOnCreate(activity, r.state, r.persistentState);
      } else {
        mInstrumentation.callActivityOnCreate(activity, r.state);
      }
    
    ...
}

进来 Instrumentation 

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
/**
 * Perform calling of an activity's {@link Activity#onCreate}
 * method.  The default implementation simply calls through to that method.
 *
 * @param activity The activity being created.
 * @param icicle The previously frozen state (or null) to pass through to onCreate().
 */
public void callActivityOnCreate(Activity activity, Bundle icicle) {
   // pre 在队列最前插入
    prePerformCreate(activity);
   // 这里就回调到了Activity中
    activity.performCreate(icicle);
  // post 在队列后面追加
    postPerformCreate(activity);
}

最后的最后来到 Activity 中

1
2
3
4
5
6
7
8
9
10
11
final void performCreate(Bundle icicle, PersistableBundle persistentState) {
    mCanEnterPictureInPicture = true;
    restoreHasCurrentPermissionRequest(icicle);
    if (persistentState != null) {
      // 调用到了onCreate
        onCreate(icicle, persistentState);
    } else {
        onCreate(icicle);
    }
  ...
}

到这里，从 main方法走到 Activity的 onCreate方法，Activity算是启动了。

好像还有个分支的坑差点忘了填，回想一下 TransactionExecutor的 execute方法，我们解释了 executeCallbacks方法，还差一个 executeLifecycleState 方法没说，这个方法见名知意，感觉像是处理生命周期状态的。具体来看下

1
2
3
4
5
6
7
8
9
10
11
12
13
14
private void executeLifecycleState(ClientTransaction transaction) {
    // 这里也是获取之前在 ActivityStackSupervisor 添加进去的 生命周期的Item
    final ActivityLifecycleItem lifecycleItem = transaction.getLifecycleStateRequest();
    if (lifecycleItem == null) {
        // No lifecycle request, return early.
        return;
    }
    log("Resolving lifecycle state: " + lifecycleItem);

    // Execute the final transition with proper parameters.
  // 同样执行 lifecycleItem 在这里就是 ResumeActivityItem 或者  PauseActivityItem
    lifecycleItem.execute(mTransactionHandler, token, mPendingActions);
    lifecycleItem.postExecute(mTransactionHandler, token, mPendingActions);
}

来看下 ResumeActivityItem

1
2
3
4
5
6
7
8
9
@Override
public void execute(ClientTransactionHandler client, IBinder token,
        PendingTransactionActions pendingActions) {
    Trace.traceBegin(TRACE_TAG_ACTIVITY_MANAGER, "activityResume");
    // 同样的，执行了ActivityThread的  handleResumeActivity 方法
    client.handleResumeActivity(token, true /* finalStateRequest */, mIsForward,
            "RESUME_ACTIVITY");
    Trace.traceEnd(TRACE_TAG_ACTIVITY_MANAGER);
}

handleResumeActivity 会执行到 performResumeActivity 最终会走到 Activity的生命周期方法 onResume。

高版本的源码的差别还是比较大的,其中涉及的比较重要的类

  • ActivityThread
  • ActivityManagerService
  • Instrumentation
  • ActivityStackSupervisor

  • TransactionExecutor

    等等

The End

2019-11-26 22:02:45

_kayce

原文作者：Sun xin

原文链接：http://sunxin.tech/2019/11/26/Activity 的启动流程源码分析/

发表日期：November 26th 2019, 5:44:52 pm

更新日期：November 26th 2019, 10:19:32 pm

CATALOG
  1. 1. Activity 的启动流程源码分析（Android 9.0）
Total : 32
2020
2019
2018
开发艺术探索 源码分析 开发艺术探索 源码 源码 设计模式 Git 面试 JavaScript 协程 Kotlin in Action Android设计模式 实用 个人博客 UML 记录 感悟 踩坑实践 随想 自定义View
Android开发艺术探索 一步一步进入高级行列 Java Android-三方开源库 设计模式系列 Git 计算机网络 JavaScript Kotlin Android技术 UML 踩坑实践 Life 源码分析 源码 Android技术/个人博客 自定义View系列